Scope is tight (+149/-1, focused on protocol surface + a small UX fix on top of #4273). Reading the code statically — did not run the test suite locally.

What looks good

• Type definition is consistent. ActiveGoalStreamEvent { type: 'active_goal', active_goal: ActiveGoal | null } in types.ts mirrors the snake_case convention used by tool_progress / content_block_*, and ActiveGoal | null accurately reflects ServerGeminiActiveGoalEvent.value in core/turn.ts.
• processEvent override reuses the existing guard. Calling emitStreamEventIfEnabled automatically respects includePartialMessages, so there is no duplicated condition. Other events go through super.processEvent(event) unchanged.
• Nice UX side-fix in goalCommand.ts. Before this PR, non-interactive /goal clear returned void, which handleSlashCommand fell back to as "Command executed successfully." (because createNonInteractiveUI().addItem is a no-op). Returning an explicit Goal cleared: <condition> is a clear improvement.
• Tests cover the meaningful axes. The stream-json test asserts both the populated ActiveGoal and the null (cleared) emission; the CLI tests cover empty /goal, set-then-status, and clear, and properly isolate the module-scoped store via __resetActiveGoalStoreForTests.

Suggestions

1. Consider ACP mode in goalCommand.ts as well. The new branch is gated on executionMode === 'non_interactive', but ACP mode also goes through handleSlashCommand with the same no-op createNonInteractiveUI(), and Session.ts#processSlashCommandResult already handles messageType: 'info' by emitting an agent message chunk to Zed. So ACP users currently get the same "Command executed successfully." fallback. Loosening the check would unify the behavior:

   if (context.executionMode !== 'interactive') {
     return infoMessage(`Goal cleared: ${cleared.condition}`);
   }

2. Optional: add a negative test for the disabled path. The "with partial messages disabled" describe block in StreamJsonOutputAdapter.test.ts doesn't assert that processEvent({ type: ActiveGoal, ... }) is suppressed. emitStreamEventIfEnabled already guards on includePartialMessages, but a single assertion would lock the behavior against future regressions.

3. Minor architectural note (non-blocking). BaseJsonOutputAdapter exposes hooks like onTextBlockCreated / onToolUseBlockCreated and keeps state mutation in the base switch. Overriding the top-level processEvent here is fine because ActiveGoal doesn't touch message state — it's a pure side-channel event. If more side-channel events land later (e.g. hook status), it might be worth introducing an onSideChannelEvent hook in the base class for symmetry. Not needed for this PR.

Risks

• Protocol-level: purely additive change to the stream_event discriminated union. Consumers doing exhaustive type-narrowing will need to handle the new variant, but that is the intended forward-compatible shape.
• state.finalized guard: the base processEvent short-circuits when state.finalized is true. The override doesn't replicate that check, but per the emit sites in core/client.ts all ActiveGoal yields happen inside the turn before Finished, so this is safe today. Worth keeping in mind if the lifecycle ordering ever changes.

Overall looks good — I'd suggest folding in the ACP branch unification before merge, the rest is optional polish.

No review findings. Downgraded from Approve to Comment: CI failing: Test (ubuntu-latest, Node 22.x). — gpt-5.5 via Qwen Code /review

Review: Approve

Product direction — sound. /goal drives the agent to keep iterating via a session-scoped Stop hook. Headless / stream-json / ACP consumers previously had no way to observe active-goal state (active? how many iterations? last judge reason?). Exposing ActiveGoal as an active_goal stream event, plus adding acp support to /goal, is a reasonable protocol-layer completion of the existing non-interactive goal capability (#4273).

Code quality — good.

• The deliberate bypass of the finalized guard is necessary and correct. maybeEmitActiveGoalChange yields ActiveGoal events after the Stop hook runs (client.ts), by which point the main message is usually finalized; the base processEvent drops events once state.finalized is true. Intercepting ActiveGoal before super is exactly what lets late goal-state changes reach consumers. Since ActiveGoal never touches mainAgentMessageState, the bypass does not corrupt the message state machine. The comment explains the why well.
• Types line up: ActiveGoalStreamEvent.active_goal: ActiveGoal | null passes event.value through directly, and the ActiveGoal fields (condition / iterations / setAt / tokensAtStart / lastReason? / hookId) match the test payload exactly.
• Correctly silent when partial messages are disabled (covered by a test).
• The clear-message change only returns an info message outside interactive mode, leaving the interactive history-card path intact.

Please confirm (non-blocking):

1. ACP set->drive end-to-end: this PR adds 'acp' to supportedModes, but the set branch still does addItem(setItem) + returns submit_prompt. Tests only cover acp clear, not whether /goal <condition> under acp actually gets the host (Zed) to consume submit_prompt and kick off the first turn. A short note or an acp-set assertion would close the gap — otherwise it may "register the hook but not auto-start".
2. Minor consistency: clear now returns a "Goal cleared: …" text receipt, but a successful set in non-interactive / acp has no "Goal set" text (it relies on the following prompt submission as implicit confirmation). A design tradeoff; fine to leave.